Service oriented architecture (SOA) is an architecture paradigm for large and complex distributed computing systems. The paradigm allows for the development, operation and control of complex distributed systems by splitting monolithic applications into components, services, or other SOA objects that can be re-used and orchestrated to get new functionality on demand. SOA objects can be connected to each other via relationships. Nowadays, complex systems are set up, comprising a huge set of relationships. In addition to SOA objects and relationships, a SOA typically comprises a SOA registry for the management of SOA objects and their dependencies. Further, SOA governance is responsible for controlling correct operations in a SOA. Operations for example comprise updating a composite relationship.
Those skilled in the art will appreciate that controlling (by SOA governance) the correct operation of a large SOA-based system is a complex and difficult task, while catastrophic impacts on the overall SOA system can arise already if one single service does not operate as expected. Given the high frequency of changes to a typical SOA, it thus has to be ensured that when a certain SOA object is updated or modified, all dependent SOA objects are updated as well in a consistent manner. For example consider a SOA system that operates a transfer system in a bank. If the referencing (source) SOA object comprises the bank account of a client as attribute and the account has been changed, the transfer might still run with the referenced (target) SOA objects conducting the transfer with obsolete bank information. In the worst case, the transferred money is lost. Therefore, it is very important to ensure that the various SOA objects of a complex SOA system are consistent at any time.
Hence, various approaches have been proposed in the prior art for controlling the correct operation of a SOA, i.e. to ensure that all participants (such as services) in the SOA operate as expected. These approaches for controlling the correct operation of a SOA are commonly referred to as “SOA governance” and include among others ensuring that all SOA components interact properly in terms of communication patterns, security rules, response times and/or other performance characteristics (quality of services), ensuring that changing a service does not impose unforeseen consequences on service consumers (change management) and/or ensuring that services evolve within the system only in a controlled manner (lifecycle management).
U.S. Pat. No. 7,512,578 B2 discloses smart containers and a definition to manage associated content without writing or modifying application code. A smart container template can represent a model including for example how items, such as items of managed content become members of a composite object of a type which the template is associated. A policy or operation specified by the definition is applied to an item, comprising the composite object, of the content.
U.S. Pat. No. 5,335,346 shows a system and method comprising an access control list for spanning across object boundaries in an object oriented database. The access control list further provides read and write access permissions and execution semantics which apply to the execution of methods in an object oriented database.
US patent application no. 2009/0024652 A1 discloses an integration server system for mapping data objects on a database schema. The system offers a strongly-typed model API, complex constraint management and association balancing. This system shows improved performance through optimized handling of ordered associations of data object and of string-valued attributes.
Further, US patent application no. 2007/0255685 A1 shows a method and system for modelling data providing a constrained design space in which data is modelled. This document discloses real world entities as objects within an object table or data store. Real world entities may include for example databases and rational links between entity objects. Relationships can be defined in a separate link database or table for referencing entity objects. This described representation of data to be modelled refers to an object hierarchy. The constrained design space allows an improved adaptation of a database in a format as one advantage.
U.S. Pat. No. 7,512,578 B2 discloses composite relationships in the context of management systems. The other above-discussed prior art approaches address a kind of system comprising objects, that may be connected with each other via relationships in databases. However, these documents do not concern service-oriented architectures with complex relationships between a vast amount of SOA objects. Therefore, the above-described prior art lacks ways for ensuring the consistency and security in a SOA system.
It is therefore the technical problem underlying certain example embodiments to provide an approach to guarantee the consistency of SOA objects in a SOA in a flexible and useable way in that SOA governance remains unaffected, thereby at least partly overcoming the above explained lacking aspects of the prior art.
This problem is according to one aspect solved by a method for propagating modification operations for Service-oriented Architecture (SOA) objects in a SOA, wherein the SOA comprises at least two SOA objects connected by at least one relationship which defines one SOA object as referencing SOA object and another SOA object as referenced SOA object. In the embodiment of claim 1, the method comprises the following steps:                a. receiving a request for propagating a modification operation from the referencing SOA object to the referenced SOA object;        b. evaluating at least one propagation rule to determine whether the requested modification can be performed on the referenced SOA object;        c. if it is determined that the requested modification cannot be performed in accordance with the at least one propagation rule, evaluating at least one approval rule to determine whether the requested modification can be performed on the referenced SOA object.        
Accordingly, the embodiment defines a method for propagating modification operations between at least two connected SOA objects. The at least two SOA objects are connected by at least one relationship which defines one SOA object as referencing SOA object and another SOA object as referenced SOA object. Typically at least three types of relationships can be considered: Simple association relationship, aggregation relationship and composite relationship.
Importantly, whenever a request for propagating a modification operation from the referencing SOA object to the referenced SOA object has been received (which may be triggered automatically by the system each time the referencing SOA object is modified), it has to be ensured, that the propagation is possible using at least one propagation rule. Certain example embodiments provide further rules for the case that the requested modification cannot be performed in accordance with the at least one propagation rule. In that case, the at least one approval rule is essential for determining if the requested modification can be performed on the referenced SOA object. In other words, certain example embodiments provide a way to consistently propagate a modification along a relationship even though the associated propagation rule does actually not allow said propagation. In this case, an additional rule, namely the approval rule, is evaluated, and if said approval rule confirms the propagation, the propagation can eventually be performed. As a result, it is ensured that modifications to SOA objects are always performed in a consistent and secure manner in that they are correctly propagated to all affected SOA objects.
In one aspect, the modification operation comprises changing at least one permission of the referencing SOA object, updating the referencing SOA object and/or deleting the referencing SOA object. For example, the at least one permission may be a read and/or write permission assigned to at least one user and/or application. In a further aspect, the modification operation comprises updating and/or creating a new relationship.
Accordingly, various modification operations can be propagated. Permissions may include read and/or write permissions and are for example assigned to at least one user. Preferably, a user who has read and write permissions (i.e. full permissions) is capable to change or update the SOA object. For example the at least one permission can be changed or updated on the referencing SOA object by the user with full permissions. Other examples include updating attributes and/or the lifecycle of the referencing SOA object and/or deleting the referencing SOA object. Modification operations are not just allowed for existing relationships, but also comprise operations such as updating/and or creating a new relationship.
In a further aspect, the at least two SOA objects are connected by at least one composite relationship or aggregate relationship.
In a further aspect, a new composite relationship is updated and/or created and propagating a modification operation is performed from the referencing SOA object to all referenced SOA objects, comprising the new SOA relationship with at least two SOA objects.
Considering composite relationships, such relationships establish a kind of hierarchy with the at least one SOA object referencing all other SOA objects. The referenced SOA objects are dependent on the referencing SOA object. If the referencing SOA object is updated according to a modification operation, the operation is propagated to all other referenced SOA objects in the hierarchy. Hence, updating the referencing SOA object implies updating all referenced SOA objects, including the SOA objects of the new relationship in the hierarchy.
In yet another embodiment, the new SOA object, i.e. the SOA object(s) affected by the new relationship, keeps the at least one original modification operation and redundant modification operations are removed. Accordingly, the present method further ensures that the modification operations are propagated to the new SOA objects with the new objects keeping the original modification operations, such as permissions. In addition redundancies are removed that can occur during propagating modification operations. This removal of redundant modification operations may be achieved via merging or alignment of SOA objects.
In a preferred embodiment, the at least one SOA object is a web service. As will be appreciated by the person skilled in the art, the term “SOA object” as used herein generally refers to a representation of a real computing entity, wherein such representation is preferably stored in a SOA registry, e.g. in the form of a WSDL definition.
SOA objects may comprise a set of attributes, including simple attributes, classifications and/or relationship attributes. Simple attributes for example have values like id, name or version. Relationship attributes are already mentioned above, including the composite relationship as one preferred embodiment. Further SOA objects may be defined by distinct types comprising the type “web service”.
In a further embodiment, the requested modification cannot be performed in accordance with the at least one propagation rule if at least one user and/or application has no write permission on the referencing SOA object.
As already explained further above the at least one user with full permissions is able to update or even delete relationships. In this case propagation of the modification operation (update or delete) is possible. However, the user might have only a read permission. In this case propagation cannot be performed.
In an aspect, detecting that the requested modification cannot be performed comprises:                Sending a message to a user and/or application; and/or        Storing a notification for being picked up by a user and/or application        
In a further aspect, the method further comprises creating a log entry if the requested modification cannot be performed in accordance with the at least one propagation rule.
In another aspect, evaluating at least one approval rule to determine whether the requested modification can be performed on the referenced SOA object comprises getting approval from a user and/or application with read and write permissions and delegating propagation of modification operations from the user and/or application with a read permission to the user and/or application with read and write permissions.
Certain example embodiments include detecting that propagation cannot be performed and storing these cases in a log. In addition if this is the case the at least one approval rule is used to obtain approval preferably from a user with sufficient permissions. Thereby propagation does not fail, but is delegated from the user with insufficient permissions to a user with sufficient permissions.
One advantage of certain example embodiments over the prior art is the support of consistency at any time, with the propagation of modification operations to referenced SOA objects. Further, undesirable requests of users with insufficient permissions are prevented supporting security aspects and in that case delegation of requests is even allowed although the user has insufficient permissions by delegation.
In a preferred embodiment of the implementation, the at least two SOA objects and/or the at least one relationship and/or the at least one propagation rule and/or the at least one approval rule are XML based and/or based on a domain specific language (DSL).
Furthermore, certain example embodiments also provide a computer program comprising instructions for implementing any of the above-described methods.
Certain example embodiments are also directed to a system for propagating modification operations for Service-oriented Architecture (SOA) objects in a SOA, wherein the SOA comprises at least two SOA objects which are connected by at least one relationship, which defines one SOA object as referencing SOA object and another SOA object as referenced SOA object, wherein the system comprises:                a. means for receiving a request for propagating a modification operation from one the referencing SOA object to the referenced SOA object;        b. means for evaluating at least one propagation rule to determine whether the requested modification can be performed on the referenced SOA object;        c. if it is determined that the requested modification cannot be performed in accordance with the at least one propagation rule, means for evaluating at least one approval rule to determine whether the requested modification can be performed on the referenced SOA object.        